Creating Web applications that respond to user requests quickly, even when a large number of requests are being processed on the server, has been a challenge for developers and IT personnel since the Internet began. Response time is the amount of time that elapses from when a client request is communicated to a server, and when the response from the server becomes interactive at the client. When an application takes a long time to respond, the user may become impatient and go to another Web site. Ideally, the client experience should appear to be that of a continuously executing process. Unfortunately, most Web Form events require communicating a substantial amount of information to the server for processing, and communicating a substantial amount of information in a response back to the client (a round trip). Such round trips often result in long response times, causing unresponsive applications and distracting user experiences.
This amount of time that it takes to perform a round trip is exacerbated because events raised by server-based Web application server controls work somewhat differently than events in traditional client forms or in client-based applications. The difference arises primarily because of the separation of the event itself from where the event is handled. In client-based applications, events are raised and handled on the client. In server-based Web Forms pages, on the other hand, events associated with server controls are raised on the client but handled on a Web server.
For events raised on the client (typically click events), the Web Forms control event model requires that the Web Form and the event information be captured on the client, encapsulated in an event message, and sending the event message to the server via a full HTTP post of the page. The page framework on the server must interpret the post to determine what event occurred and then call the appropriate server method(s) to handle the event. Once the event has been processed, the server generates a completely new page with the server controls associated with the client-side user interface (UI) elements by rendering the HTML data for each of the client-side UI elements. The server then performs a full page postback of the newly rendered page—an entire new Web Form—to the client in an HTTP response. This means that for each action that requires processing, the entire form must be submitted to the server, the entire form must be recreated, processed, and returned in a full page postback to the client. This sequence of events is called a round trip.
For example, imagine a business scenario: A user enters an order on a Web Forms page (“page”). Responsive to order entry, and to confirm sufficient inventory for the order, an application posts the page to the server at an appropriate point in the user's order-entry process. The server receives the post, identifies resources of the page, generates a control object hierarchy for the identified resources, examines the order, performs an inventory lookup, perhaps takes some action defined in business logic (such as modifying the page to indicate an error), and based on the results of the order entry in view of the business logic, renders the resulting page HTML for client-side presentation. At this point, the server returns the page in a full page postback to the browser for the user to continue.
In view of the above, full Web page submittals and full Web page postbacks for a server to handle a client application event are substantially problematic in that they typically result in a non-responsive application, which in turn generally leads to a poor user experience. To make matters worse, each full page post to a Web server to handle a client-side event may add an extraneous step to an application's page navigation history. For example, consider that a full page post by a Web browser application to a Web server creates an irrelevant step in the page's navigation history. In this scenario, if a user selects the browser's “back” navigation button, the browser will present a previous rendering of the same page, which is not the “real” previous page. As can be appreciated, generating such an extraneous navigation step in a page's navigation history responsive to a full page post is a substantial waste of processing power, resources, time, and can be confusing and frustrating to a user of the application. Accordingly, systems and methods to facilitate the appearance of a continuously executing process to a user when processing Web page events that do not generate extraneous page navigation steps, would be welcomed.